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TECHNICAL FIELD OF THE INVENTION 

The present invention generally relates to mobile communications, and in particular to 
AAA support for mobile IP (Internet Protocol), specifically authentication and/or 
authorization. 

BACKGROUND OF THE INVENTION 

Mobile IP (MIP) defines a method that allows a Mobile Node (MN) to change its point 
of attachment to the Internet with minimal service disruption. MIP in itself does not 
provide any specific support for mobility across different administrative domains, 
which limits the applicability of MIP in a large-scale commercial deployment. 



AAA (Authorisation, Authentication, Accounting) protocols such as the Diameter 
protocol precisely enable mobile users to roam and obtain service in networks that 
may not necessarily be owned by their home service provider. For MIP to be deployed 
in commercial networks, there therefore has to be AAA support for the protocol. The 
20 general architecture for MIP AAA is illustrated in Fig. 1 . 

For the case of Mobile IPv6 (MIPv6) [1], an Internet draft [2J has been proposed 
winch specifies a new application to Diameter that -enables MIPv6 roaming in 
networks other than the home domain network. Very recently, an Internet draft [3], 
which defines an architecture and related protocols for performing dynamic Mobile 
IPv6 authorization and configuration relaying on an AAA infrastructure, has been 
published. In this draft, the necessary interaction between the AAA server of the home 
provider and the mobile node is realized using EAP (Extensible Authentication 
Protocol), exploiting the capability of some EAP methods to convey generic 
30 information items together with authentication data. This approach has the advantage 



that the access equipment acts just as a pass-through for EAP messages and therefore 
does not play any active role in the Mobile IPv6 negotiation procedure, which makes 
the solution easier to deploy and maintain. The Internet draft [4] defines the 
Command-Codes and APVs necessary to carry EAP packets between a Network 
Access Server (NAS) and a back-end authentication server. 

Fig. 2 schematically illustrates an exemplary HMIPv6 domain. Hierarchical mobility 
management for Mobile IPv6 reduces the amount of signaling between the MN, its 
Correspondent Nodes (CN), and its HA by using a Mobility Anchor Point (MAP) 
located in the visited network, which improves the performance of Mobile IPv6 in 
terms of handoff speed [5]. An MN entering a MAP domain will receive Router 
Advertisements containing information on one or more local MAPs. The MN can bind 
its current location (on-link Care of Address or LCoA) with an address on the MAP's 
subnet called Regional Care of Address (RCoA). Acting as a local HA, the MAP will 
receive all packets on behalf of ihe MN it is serving and will encapsulate and forward 
them directly to the MN's LCoA. 

HMIPv6 itself, as in the MIP case, does not provide any specific support for mobility 
across different administrative domains, which limits the applicability of HMIPv6 in a 
large-scale commercial deployment. 

It can normally be expected that the MN would need to be authenticated first before 
being authorized to use the services of HMIP. It is crucial that the security relationship 
between the mobile node and the MAP is of strong nature; it must involve mutual 
authentication, integrity protection and protection against replay attacks. To this end, 
distribution of security keys between MN and MAP currently has to rely on Public 
Key Infrastructures (PKI) and complex protocols. The current HMIP draft [5] also 
limits the location of the MAP to the visited network. 
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THE INVENTION 

It has been recognized that there are cases where it would be beneficial to have MAP 
located in the home network or other networks, such as for the case where the visited 

5 network does not provide MAP support. A MAP located in the home network can be 
used to address the HA scalability issues, offloading the HA by reducing the number 

. of binding updates that go to the HA during intra-MAP domain mobility. By selecting 
the MAP to be topographically close to the location of the MN, fast handovers can be 
realized. An example of MAP located in the home network is illustrated in Fig. 3. 

10 

Among other things, the invention proposes solutions for AAA support for HMIPvS, 
, and specifically authentication and/or authorization support. For example, a "Diameter 
HMIPv6 Application" is created which carries HMIPv6 related information facilitating 
discovery of MAP, dynamic allocation of MAP, dynamic allocation of RCoA, 

15 distribution of security keys between MN and MAP, and possible piggyback of 
HMIPv6 mobility procedures. Also, as a possible complement and/or alternative to the 
Diameter HMEPv6 Application, a new EAP authentication protocol "HMIPv6 
authentication method" or "EAP/HMIPv6" is defined mat can carry the above 
HMIPv6 related information - a suitable EAP carrier such as the Diameter EAP 

20 Application can then transport EAP/HMIPv6 within the AAA infrastrucnire. 
Furthermore with AAA support for HMIPv6, additional scenarios where MAP is 
located in the home network or other network than the visited become a possibility. 

In the following, exemplary aspects of the invention will be described, including 
25 preferred features as well as optional features. 

(1) A novel architecture for HMIPv6 AAA, as illustrated in Fig. 4. 

A new EAP authentication protocol "HMIPv6 authentication method" or 
"EAP/HMIPv6" is defined that carries HMIPv6 related information facilitating 



(2) 
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for example discovery of MAP, dynamic allocation of MAP, dynamic 
allocation of RCoA, distribution of security keys between MN and MAP, and 
possible piggyback of HMIPv6 mobility procedures. A suitable EAP carrier 
such as the Diameter EAP Application can then transport EAP/HMlPv6 within 
the AAA infrastructure. 

EAP/HMlPv6 is a superset of EAP/MIPv6 which is described in detail in 
Appendix A, and defines in addition, new HMBP-specific Type-Length- Values 
(TLV's). By including the TLV's of EAP/MIPv6 as part of EAP/HMIPv6, it 
will be possible to accommodate simultaneous executions of both MIPv6 and 
HMIPvfi authentication and/or authorization in a single traversal which enables 
shorter setup times. It would also be possible to execute only HMIPv6 
authentication and/or authorization without the MIPv6 counterpart and vice 
versa, depending on the particular need of the MN at a specific instance. This 
allows a single EAP authentication protocol EAP/HMIPv6, to be flexibly used 
on various use case scenarios. 



The use of EAP allows the AAA Client (and AAAv) to be agnostic to HMIP 
procedures (i.e., this removes dependency on HMIP support of the visited 
network), and act as mere pass-through agents), which is one of the major 
advantages of using EAP. 

Furthermore, piggyback of HMIPv6 mobility procedures in EAP/HMIPv6 
allow possible shortening of overall setup times by optimizing authentication, 
authorization, and mobility in a common procedure. 

A "Diameter HMIPv6 Application" is created which carries HMIPv6 related 
information facilitating for example discovery of MAP, dynamic allocation of 
MAP, dynamic allocation of RCoA, distribution of security keys between MN 
and MAP, and possible piggyback of HMIPv6 mobility procedures. 
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The Diameter HMIPv6 Application is a superset of the Diameter MIPv6 
Application described in [2], and defines in addition, new HMIP-specific 
command codes, AVP's, and/or flags. By including the command codes, 
AVP's, and flags of the Diameter MIPv6 Application as part of the Diameter 
HMIPv6 Application, it will be possible to accommodate simultaneous 
executions of both MIPv6 and HMIPv6 authentication and/or authorization in a 
single traversal which enables shorter setup times. It would also be possible to 
execute only HMIPv6 authentication and/or authorization without the MIPv6 
counterpart and vice versa, depending on the particular need of the MN at a 
specific instance. This allows a single application, the Diameter HMIPv6 
Application, to be flexibly used on various use case scenarios. 

Furthermore, piggyback of HMIPv6 mobility procedures in Diameter HMIPv6 
Application allows possible shortening of overall setup times by optimizing 
authentication, authorization, and mobility in a common procedure. 

The location of MAP can be in the home network, visited network, or other 
networks. There is no longer mandatory dependency on the Router 
Advertisements containing information on MAPs within pre-defined MAP 
domains. Technically, it would be possible for the MN to bind with any MAP 
as long as an RCoA on the MAP can be obtained with AAA support, if 
operators allow this. 

25 (5) Reassignment of MAP may occur during the following cases: 

• Expiration of security keys between MN and MAP - for this case, the 
MN initiates HMIPv6 re-authentication / authorization, and the network 
may assign a different MAP that is more appropriate based on, e.g., 
30 current topological location of MN 



At the request of MN (MN initiated) - for this case, the MN initiates 
HMIPv6 're-authentication / authorization requesting for reassignment of 
MAP 

At the request of the network (network initiated) - for the case, either the 
AAAh or AAAv initiates the reassignment of MAP and "pushes" this to 
the MN when the need arises, e.g., when the MN moves to an AR that is 
better covered by a new MAP. 

(6) The possible different protocol combinations between the segments AAA 
Client - AAAh, and AAAh - (AAAv) - MAP are summarized below: 



AAA Client <-> AAAh 


AAAh <-> (AAAv) <-> MAP 




(i) Diameter HMIPv6 Application 


Diameter HMlPv6 Application 




(n) • Diameter/EAP/HMIPv6 


Diameter HMIPv6 Application 




tin) Diameter/EAP/HMlPv6 


Diameter/EAP/HMIPv6 



Note: (Hi) is applicable for the case where the MAP is located in the home 
network. 



Where MAP is located in the visited network, the AAAv may be involved in 
the selection of MAP based on visited network policy. 

EAP/BMIPv6 Protocol Details 



In the following, details of an exemplary EAP/HMIPv6 protocol are defined. New 
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EAP TLVs are defined that would cany information that facilitate for example 
discovery of MAP, dynamic allocation of MAP, dynamic allocation of RCoA, 
distribution of security keys between MN and MAP, and possible piggyback of 
HMIPv6 mobility procedures. The TLV's of EAP/MJPv6 are also part of 
5 EAP/HMIPv6. 



An exemplary summary matrix of EAP/HMlPv6 TLV's is given below in Table I: 



flAftHMirvfi Typc*Lcneih«Vatuo 


Source 


Destination 


Purpose 


Comment 


HMUW ipccifeTt.V'1: 






icqurtiUCoA 




ttCoA Iteprtt CAP.Ttv uuibwa 


MM 


AAAh 




OCoA ScipOaK SAMIV ((tribute 


AAAh 


MN 


RCoA 


MAPfaham. 
MA»h«{cticd 


AAAh 


MN 


*m»«fd KCM Stem AAA* 


KCoA EaP*TLV •mi&ne 


AaAH 


MAT 


MiltiiACuA 


MAprnhoaic 


MAT aMi« Rcqocii EAP-TIV araribuia 


MN 


AAAh 


icqtmtMAPaddrcn 




• MaP Adfficu AopcHu* iisibua 


AAAh 


MM 


mgnMAPtdfoa 


MATmhoin* 




AAAh 


MN 


M MAT *Uliew ftnm AAA* 


MAPuivfthta 


MAP« MM fa*fhltt4 Key Gmcmimi None* EaP.TXV anribUu 


MN 


AAAh 


tei<ffcrMN*MAPkcy 


MATmheaa 


• MAr44Pr*ntuted*cy£Ar-U.Vavfbwe 


AAAh 


MAT 


MN-MAP Uy 


• MAT rKC KrytO £AfXl.V MtxMc 


AAAH 


MN 




MAP m ho«X 


MAr-MN irsccsn qap-ylv »tmt»* 


MAT 


MNwbAAAb 




MAP to ham, 


AAAh 


MH 


fcr+tri Horn MAT 


MAP ia Wrftrit 


• MaP-MN IPSce ffotocol GAP-TLV wuibuor 


MaP 


MM r!» AAAh 


aulpi irsoc rtotocoi 


MAPtnitome 




AAAh 


MN 




MA? tn vitluU 


• MAP-MN iPSec Crypto C *P.Tl> inrihui* 


MA? 


MN «ia AAAh 


uncBlfSceOypto 


MAPinhfunc 


AAAh 


MM 


Camanl ftaaiMAP 


MAPi&vhSlCil 


• MaP.mW tPSce lUy litem* CaP-Tl* tnnbaic 


MAP 


MN *U AAAb 


a**ig* TPSee Key L&umt 


MAP in lam 


AAAh 


MN 


fhnwdtowMAP 


MAPia«hfted 


HMIf-Oiadins-Upitm CAP-TLV aaribua 


MN 


MAP «U *AAh 


pij^yhatk I EMI? binding UpOStt 


MAP hi home 


MN 


AAAb 


pifiOhaeV HMJP blatioe apilM 


MAP la Wfiwd 


HMlP-ddMlki:-A**no«trrfc««afl KAP-TLV Mrihac 


MAP 


MN ~uAAAh 


pi££ybMk MMlP btoJinj «*. 


MAP iaboffit 




AAAb 


MN 


icrvtord Attn MAP 


MAPaivtsKcd 


Nt* M1P«6 spafe Ti V. (giQ0Ow4 i«vnw«tin to CAf /Mff »6 TtV tci>: 




Ma 






• MfP%* Kmc aUiui CAP-TLV nitfbutt 


AAAh 


«siiS<i MN Hows AtfiCn 




• Ka-MN Pwihflc* Key £A/-TLV vwibu* 


AAAb 


ItA 


•Mien HA-MN tty 




llA-MX' JPSfe Prececal EAP-TLV *wnbure 


MA 


MN«mAAAh 


ttttipITSrcrtfitacel 




Ha-MK IPScc Gyp» CAP-TtV mrfbafo 


IIA 


MN vUAAAl. 


xsrt^n IPSc« CiyplO 




MU».ai8diag4Jp<t« fAP-TXVattriiutt 


MN 


IIA «u AAAh 


flSeyhKh MIP Wftdbqi op4s» 




• MIP.ftb6qt-A**w!rfcc«w £aPTLV aanW 


IE* 


MN «• AAAh 


figgyhwk MIPbiQdId tt avk. 




Skirt* EA//Mjr«« TLV» (CAP/Mjp^jr 










M1>S CtttUcitgC fiAP-TLV ivibpte 


AAAh 


MM 


inoochJhmst 




MAS Onponu EaPVH.V uwiJraic 


MN 


AAAb 






MSPvtf Home Aflfljtu ttotfutu BAP-T^V tfribue 


MN 


AAAh 


nqpA MM kcmc addnw 




MtKft KtoJtt AAJtrn R*tp~wc Ra/TLV uiribut* 


AAAh 


MN 


Wifio MN San» addwes 




Mlf *4 ties* Ag«* Atfdrcn ftajwrri EAPVJT.V «sstbttrc 


MN 


AAAft 


rtooa HA Md«tt 




MTP»6 Hotnr AfiOl AtfdfCu flUxpow* OAP.Tl,v niufcutt 


AAAh 


MN 


atffjjn Ha *Afrct l 




Ha-MV Ptr4&ttcd Key Cwtrwno N'oaw 6AT-TX.V ,mnha» 


MN 


AAAh 


teed Tor KA-MN h«y 




• IKS Kc/10 fiAT-TLV wtntoc 


AAAh 


MN 


mis f» oiwo.j Wa-MN pre-ibuvd Xrj Rem AAA* 


• IXAACN fPScc SPI EA#*UV isriboxc 


HA 


MN «u AAAh 


MnchSfi 




Wa MN If See Key UMm RaP-IX* jttributr 


IIA 


MNwil AAAh 


j»^o IP $«t K*y b'fctbwe 




f ACf AA PrrHhwci! Key Onxnaos Non*c P.AP*TL v tflAtmt* 


MM 


AAAh 


ucd^hrPACPAAkcy 
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Note: the IKE KeylD includes some octets which informs the HA/MAP how to retrieve 
(or generate) the HA-MN pre-shared key/MAP-MN pre-shared key from AAAh. 
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Figs. 5 and 6 show exemplary general signaling flows for HMIPv6 AAA using 
Diameter/EAP/HMiPv6 (simultaneous MlPv6 + HMIPv6 initiation requests). In 
particular, Fig. 5 illustrates Diameter/EAP/HMIPv6 signaling flow for the MAP in 
home network case. Fig. 6 illustrates DiameteiflEAP/HMlPv6 signaling flow for the 
MAP in visited network case (Diameter HMIPv6 Application is used between AAAh 
and MAP). 



Diameter HMIPv6 Application Protocol Details 



Details of the Diameter HMIPv6 Application protocol are defined below. New HMIP- 
specific command codes, AVP's, and/or flags are defined that would carry information 
that facilitate for example discovery of MAP, dynamic allocation of MAP, dynamic 
allocation of RCoA, distribution of security keys between MN and MAP, and possible 
piggyback of HMIPv6 mobUity procedures. The command codes, AVP's, and flags of 
15 the Diameter MIPv6 Application arc also part of the Diameter HMIPv6 Application. 



An exemplary summary matrix of Diameter HMIPv6 Application Command Codes 
and AVP's is given below in Table 2: 



Diameter RMirs* Application Command Code* ami AVp*7 


Soare* 


DcirfnaUoft 


Pvrpose 


Commcot 


HMW cpcctfit coRinnd cofo 

MAP^MJPvf.R«pra Ccmnwnd (Ma«) 

MAP ^IMhkMMt CsflUKftlMI (MAA) 


AAA* 
AAAh 
MAP 
HAP 


MAP 

KA?vt«AAAw 
AAAf) 

AAAh vt* ^J^A* 


MCJ^crofMMLP AV?> 

whwjt nr mmipavk 
Melange arkMJP avpv 


MAPfctliOfW 
MAPinwjiud 
map ; n htm 
MAP u »l|licd 


IWHMIJfl dlnrwta^diOttfiu AVP 

RCmAVP 

[ MA'AOfonAVP 

MAf-*«i«s«nl«na 






HMiP Surfing urastc messsp 

IIMTP drnding Aitoo*Utf S cnwrt 
tax byMArioMN 

RCoa 

MAPiddraj 

nqsnu fcr • 4ynttHS MAP 




BMttMft O.'tmacr WTWc Arofudron (wim»d coder 

Aa &tcmdi»tltqtra Cowniitu fARA) 
AARcgmrniMAjn^or CoftnuMOtAftA) 
MOuKApnvM il*>6>JU<tum Command (KOft) 
Mcme-Atew.MTPv*. « w»c* Ccmuttftd <HOA> 


AAACKem 
AaAJi 
AAAh 
HA 


AAAh (m aaa >f) 
AAA Client (ma aaAv) 
HA 
AAAh 






B»*iBa0i«i«iirM!W6 AftffibaiM aVPV 

MilMit««« c .UpAdrAVi> i 

«I^6.K0P*. V.e«- Arfdfen AVP 

Mff rt-Peuu/r- v«w a vp 






Mobile IP Qindui5U|HUrc inciuft 
•em by MN to Ma 
MoM«IP Bifulmi; 
AtWfl*icfl£oiwn> sim by HA to 
MM 

The Mobile Node's Horn* Attrai 

tfw Mobile nmc'I Hue* A(rm 
Addnss 

t etyiaif far 4 dynamic hnm« « go* 





Figs. 7 and 8 show exemplary general signaling flows for HMIPv6 AAA using 
Diameter HMIPv6 Application (simultaneous MIPv6 + HMIPv6 initiation requests). 
In particular, Fig. 7 illustrates Diameter HMIPv6 Application signaling flow for the 
MAP in home network case. Fig. 8 illustrates Diameter HMIPv6 Application signaling 
flow for the MAP in visited network case. 

Among other application areas, the invention is applicable to all access networks such 
as WLAN, CDMA2000, WCDMA and so forth, where MIPv6/HMlPv& can be used, 
including technologies such as AAA and IPv6 mobility, systems such as CMS 11, 
WCDMA and GSM systems, sub-systems such as service/application subsystems and 
terminals, and products such as AAA servers, Home Agent Servers and terminal 
nodes. 



The embodiments described above are merely given as examples, and it should be 



10 

understood that the present invention is not limited thereto. Further modifications, 
changes and improvements which retain the basic underlying principles disclosed herein 
are within the scope of the invention. 
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AAA - Authentication Authorisation and Accounting 
AAAh - Home AAA Server 
AAAv - Visited AAA Server 
AR - Access Router 

ara - AA-Registration-Answer Command 

ARR - AA-Registratiort-Request Command 

AVP - Attribute-Value Pair 

CN - Correspondent Mode 

EAP - Extensible Authentication Protocol 

HA - Home Agent 

HMlPv6 - Hierarchical Mobile IP version 6 

HOA - Home-Agent-MlPv6-Answer Command 

rJOR - Home-Agent-MIPv6-Request Command 

ICMP - Internet Control Message Protocol 

IKE - Internet Key Exchange 

IPsec - IP Security 

LCoA - ort-Unk Care of Address 

MAP - Mobility Anchor Point 

MD5 - Message Digest 5 

MIP - Mobile IP 

MIPv6 - Mobile IP version 6 

MN - Mobile Node 

PANA - Protocol for Carrying Authentication for Network Access 
PKI - Public Key Infrastructure 
RA - Router Advertisement 
RCoA - Regional Care of Address 
TLV - Type-Length-Value 
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EA^/HMIPv6(Success 
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intity) 
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APPENDIX A 



Mobile TPv6 (MIPv6) capable mobile nodes, such as cellular phones, laptops and other 
end-user equipment, can roam between networks that belong to their home service 
provider as well as others. Roaming in foreign networks is enabled as a result of the 
service level and roaming agreements that exist between operators. One of the key 
AAA protocols that contribute to making this kind of a roaming mechanism possible is 
Diameter and the general architecture for MIPv6 AAA is schematically illustrated in 
Fig. 1. 

Finding a well-functioning and complete MIPv6 AAA solution combining mobility 
with authentication/security for mobile communication would be very desirable. For 
instance, AAA can then be used to check/control who is entering the network. 
However, in the prior art only partial solutions are presented. These are generally non- 
consistent with each other and do not work end to end. 

In [4], for example, attempts are made to specify a new application to Diameter 
enabling Mobile IPv6 roaming in networks other than the home domain. The Internet 
draft identifies information that typically needs to be exchanged between a MN and an 
AAA Client in the network and suggests use of the new Diameter application in 
exchanges of this information between AAA Client and AAAv, between AAAv and 
AAAh, and between HA and the AAA infrastructure. However, no particular 
mechanism to convey information between the mobile node and the AAA Client is 
specified. This, together with other shortcomings, makes this solution unsatisfactory 
and non-complete. 

Thus, the need for an appropriate mechanism for MIPv6 AAA remains. 

It is desirable to provide a complete mechanism for combining terminal mobility and 
user authentication in networks with mobile nodes, and to enable MIPv6 AAA. 
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This is achieved by means of a new BAP authentication protocol referred to as 
"EAP/MIPv6 n (or "MIPv6 authentication method"). Preferably, the invention enables 
MIPv6 AAA by using a combination of PANA Jand Diameter as earner protocols. The 
EAP/MIPv6 protocol can carry information that facilitates MIPv6 authentication, as 
5 well as dynamic MN home address allocation, dynamic HA allocation, distribution of 
security keys between HA and MN, and distribution of security keys between PAC 
and PAA for PANA security. 

PANA is preferably used in carrying EAP/MIPv6 between MN/PAC and PAA/AAA 
10 Client. There are alternative cannier protocols, though. Diameter EAP Application [3] 
is generally used to transport EAP/MIPv6 between PAA/AAA Client and AAAv, and 
between AAAv and AAAh. The Diameter protocol is also used by AAAh for 
assignment to PAA/EP of security keys for PANA security, optional MIP packet filters 
via MIP filter rules, and optional QoS parameters etc. However, there may be 
15 embodiments using another suitable AAA protocol, such as Radius, instead of 
Diameter. 

The exchanges between HA and the AAA infrastructure may for instance follow the 
AAAh-HA interface protocol specified in Diameter MIPv4 Application [2], or 
20 alternatively employ a mechanism similar to thkt currently used in 3GPP2 (i.e. [9]) in 
conjunction with the IKE [8] framework. 

MlPv6 handoffs use a subset of the procedures used for MIPv6 initiation. For the 
handofifcase, EAP/MIPv6 would only need to carry information that facilitates MIPv6 
25 authentication, and distribution of security keys between PAC and PAA for PANA 
security. 

For the case where EAP is used for WLAN authentication, e.g., EAP/AKA, PANA can 
be used for transporting EAP/AKA between PAC and PAA for WLAN access 
30 authentication instead of [10]. By carrying multiple EAP sequences in a single PANA 



sequence, both EAP/AKA authentication of WLAN and EAP/MIPv6 can take place 
within a single PANA sequence for optimization purpose. 

According to the authentication method of the invention, new EAP TLVs are defined 
for carrying MIPv6 authentication information. In case MD5 challenge authentication 
is used, these typically includes a MD5 Challenge attribute and a MD5 Response EAP- 
TLV attribute. 

The authentication protocol preferably defines a number of additional EAP TLVs for 
dynamic MN home address allocation, dynamic HA allocation and distribution of 
security keys between HA and MN. These attributes are optional and there may be 
implementations lacking some or all of them. Furthermore, for distribution of security 
keys between PAC and PAA for PANA security, a PAC-PAA Pre-shared Key 
Generation Nonce EAP-TLV attribute is generally needed. 

By means of the attributes like these, the EAP protocol is allowed to carry MIPv6- 
rclated auxiliary information, such as requests for dynamic MN home address 
allocation, dynamic Home Agent allocation, as well as nonces/seeds for creation of 
necessary security keys, in addition to the main IPv6 authentication information. This 
is a major advantage of the invention. 

Introductory discussion 

As mentioned in the background section, a proposal which attempts to specify a new 
application to Diameter that enables Mobile IPv6 roaming in networks other than its 
home has been raised in IETF [4]. It identifies the following information that typically 
needs to be exchanged between a MN and an AAA Client in the network: MIP Feature 
Data, EAP Data, Security Key Data, and Embedded Data. It also specifies the use of 
the new Diameter application in exchanges of the above information between AAA 
Client and AAAv, between AAAv and AAAh, and between HA and the AAA 
infrastructure. 
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Although [4] docs not specify any particular mechanism to convey information 
between the mobile node and the AAA Client, the possibility to use the protocol 
defined by the IETF PANA WG has been mentioned. On the other hand, the PANA 
WG has recently identified EAP [6] as the payload for the PANA protocol and carrier 
5 for authentication methods [1]. In other words, PANA will carry EAP, which can carry 
various authentication methods. By the virtue of enabling transport of EAP above IP, 
any authentication method that can be carried as an EAP method is made available to 
PANA and hence to any link-layer technology. The PANA WG has assumed a clear 
division of labor between PANA, EAP and EAP methods. Defining new 
10 authentication methods, or deriving/distributing keys is considered outside the scope 
of PANA. Providing a secure channel that protects EAP and EAP methods against 
eavesdropping and spoofing is also not an objective of the PANA design. 

This implies that apart from carrying the EAP, the PANA protocol will not be able to 
15 transport the other MfPv6-related auxiliary information such as MIP Feature Data, 
Security Key Data, and Embedded Data. Thus, there is no satisfactory prior-ait 
mechanism for MIPv6 roaming . in foreign networks and conveying necessary 
information between MN and AAA Client. 

20 Another drawback of the solution in [4] is that it requires the AAA Client (and AAAv) 
to understand the authentication method and be aware of the contents of the exchanges 
(MIP Feature Data, EAP Data, Security Key Data, and Embedded Data) between the 
MN and the AAAh. It will not be possible to let the AAA Client act as mere pass- 
through agent, which is one of the major advantages of using EAP (and one of the 

25 assumptions for using PANA). Neither will it be possible to apply prior encryption 
between MN and AAAh (e.g., EAP/TTLS [5]) and the exchanges will be visible over 
the air interface. Security against eavesdropping, man-in-the-middle and other attacks 
is likely to be compromised. 
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These drawbacks and others are overcome by (he present invention, according to 
which an EAP authentication protocol is proposed for combining the terminal mobility 
of MlPv6 with the user authentication of AAA in a most advantageous way, achieving 
a complete MIPv6 AAA solution. 

5 

Main principles as well as implementation details of the invention will now be 
described by way of example. General reference is made to the MIPv6 AAA actors 
and architecture illustrated in Fig. 1. 

10 MIPv6 AAA using PAN A and Diameter Combination 

A new EAP authentication protocol u EAP/MIPv6" is defined to cany a "MIPv6 
authentication method". EAP/MIPv6 should enable negotiation/enforcement of MIPv6 
authentication (main goal), as well as support some auxiliary information that facilitate 
e.g., dynamic MN home address allocation, dynamic HA allocation, distribution of 

15 security keys between HA and MN, and distribution of security keys between PAC 
and PAA for PANA security. PANA is preferably used in carrying EAP/MIPv6 
between MN/PAC and PAA/AAA Client. Alternatively, carrier protocols which 
satisfy EAP requirements on lower layer ordering guarantees as in PPP and [10] may 
be used to carry EAP/MIPv6 between the MN and AAA Client. Specifically for the 

20 3GPP2 CDMA2000 case, it is possible to carry EAP/MIPv6 between the MN and 
AAA Client using PPP Data Link Layer protocol encapsulation with protocol field 
value set to C227 (Hex) for EAP [6]. 

A preferred embodiment uses Diameter for communication between the AAA client 
25 and home server. Beyond the PAA/AAA Client towards and within the AAA 
infrastructure, Diameter EAP Application [3] is then used to encapsulate EAP/MIPv6 
within Diameter, that is, EAP/MIPv6 is carried between the PAA/AAAClient and 
AAAh. The Diameter protocol is used by AAAh for optional assignment of MIP 
packet filters via MIP filter rules to the PAA/EP and HA, which correspond to the 
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filter enforcement points. The Diameter protocol is also used by AAAh for distribution 
of security keys to PAA for PANA security, and optional signaling of QoS parameters. 
It should be noted that even though Diameter is the preferred choice, it may sometimes 
be appropriate to instead use another AAA protocol, such as Radius, with 
5 modifications obvious to the man skilled in the art. 

Regarding the communication between HA and the AAA infrastructure for exchange 
of security keys (necessary to establish SA between HA and MN) and accounting, two 
possibilities are suggested. One possibility is to employ the AAAh-HA interface 

10 protocol specified in Diameter MIPv4 Application [2]. Another possibility is to 
employ a mechanism similar to that currently used in 3GPP2 (i.e. [9]) in conjunction 
with the IKE [8] framework, to distribute dynamic pre-shared keys between MN and 
HA- A KeylD js used by the HA to retrieve (or generate) the HA-MN pre-shared key 
from the AAAh (exactly how this is done is vendor/operator implementation specific, 

15 and out of scope of this patent disclosure). The KeylD is generated by the AAAh and 
upon successful authentication sent to the MN, which in turn sends it to the HA using 
IKE. 

MlPv6 handoffs use a subset of the MIPv6 initiation procedures described above. For 
20 the handoff case, since the MN has already been previously assigned a home address 
and a HA prior to handoff, EAP/MIPv6 would only need to carry information that 
facilitate MIPv6 authentication, and distribution of security keys between PAC and 
PAA for PANA security. The MIPv6 authentication which takes place is for 
authentication to use the newly acquired CoA. As with the MIPv6 initiation case, 
25 Diameter protocol is used by AAAh for assignment to P AA/EP of optional MIP packet 
filters via some kind of MIP filter rule, security kfeys for PANA security, and optional 
QoS parameters etc. 

When both EAP/AKA for WLAN access authentication, and EAP/MIPv6 have to be 
30 carried out, it is proposed to allow single traversal to carry out both simultaneously to 
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save time and facilitate fast handoff (both AAAv and AAAh are traversed). PANA is 
used in carrying EAP/MIPv6 between PAC and PAA/AAA Client PANA can also 
used for transporting EAP/AKA between PAC and PAA for WLAN access 
authentication instead of [10]. By carrying multiple EAP sequences in a single PANA 
5 sequence, both EAP/AKA for WLAN authentication and EAP/MIPv6 can take place 
within a single PANA sequence for optimization purposes. 

New EAP attributes and exemplary signal flows 

In this section, implementation features of the proposed authentication protocol 
10 according to the invention will be described. Examples of EAP/MIPv6 protocol details 
are provided to show the overall flow and viability of concept. 

The authentication method of the invention involves new EAP TLVs carrying 
information that facilitates MlPvjS authentication, dynamic MN home address 
15 allocation, dynamic HA allocation, distribution of security keys between HA and MN, 
and distribution of security keys between PAC and PAA for PANA security. 

The following new EAP TLVs are preferably defined under EAP/MIPv6: 

MD5 Challenge EAP-TL V attribute 
20 MD5 Response EAP-TL V attribute 

MIPv6 Home Address Request EAP- TL V attribute 

MIPv6Home Address Response EAP-TLV attribute 

MIPv6 Home Agent Address Request EAP-TLV attribute 

MIPvC Home Agent Address Response EAP-TLV attribute 
25 HA-MN Pre-shared Key Generation Nonce EAP-TLV attribute 

IKE Key ID EAP-TLV attribute 

HA-MN IPSec SPI EAP-TL V attribute 

HA-MN IPSec Key Lifetime EAP-TLV attribute 

PAC-PAA Pre-shared Key Generation Nonce EAP-TLV attribute 
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By means of (some or all of) these attributes, the EAP protocol can, in addition to the 
main IPv6 authentication infoimation, cany MIPv6-related auxiliary information, 
which is a considerable advantage. The MIPv6-related auxiliary information can e.g. 
comprise requests for dynamic MN home address allocation, dynamic Home' Agent 
5 allocation, as well as nonces/seeds for creation of necessary security keys. 

Different authentication protocols are possible for EAP/MIPv6. A preferred 
embodiment of the invention proposes implementation through MDS-Challenge 
authentication, but other protocols also lie within the scope of the invention. The 
10 following EAP-TLV attributes are defined for MIPv6 authentication: 

i) MD5 Challenge EAP-TLV attribute 

This represents the octet string generated randomly by the AAAh and sent to MN for 
MDS challenge. 

15 ^ 

ii) MDS Response EAP- TL V attribute 

This represents the octet string generated as a result of MDS hash function with the 
shared secret key between AAAh and MN. 

20 The following EAP-TLV attributes are preferably defined for dynamic MN home 
address allocation: 

iii) MIPv6 Home Address Request EAP-TLV attribute 

This represents a request for a dynamically allocated MIPv6 home address for the 
25 authenticated MN. It will be requested by the MN to the AAAh when the MN initially 
requests to be authenticated and given MIPv6 service. This attribute is optional when 
the MN already has a previously assigned home address, e.g., during MTPv6 handoffs. 

iv) MIPv6 Home Address Response EAP-TLV attribute 
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20 



This represents a dynamic allocated MIPv6 ho ne address for the authenticated MN. It 
will be notified to the MN from AA Ah when tf e MN, which has requested for one, has 
been successfully authenticated. This attribute is optional when the MN already has a 
previously assigned home address, e.g., during MIPv6 handoffs. 

The following EAP-TLV attributes are preferably defined for dynamic HA allocation: 
y) MIPv6 Home Agent Address Request EAP-Z r , V attribute 



This represents a request for an address of a 



10 when successfully authenticated. It will be requested by the MN to the AAAh when a 



dynamically allocated HA for the MN 



MN initially requests to be authenticated anc 



protocol has a dynamic HA discovery methed to allocate the HA, this attribute is 
optional. This is also the case when the MN already has a previously assigned HA, 
e.g., during MIPv6 handoffs. 



given MIPv6 service. As the MIPv6 



TLV attribute 

:d HA for the authenticated MN. It will 



vi) MIPv6 Home Agent Address Response EAP 
This represents an address of a dynamic allocat 
be notified to the MN from the AAAh \rtien a MN initially requests to be 
authenticated and given MIPv6 service. As thi MIPv6 protocol has a dynamic home 
agent discovery method to allocate the home kgent, this attribute is optional. This is 
also the case when the MN already has a previously assigned HA, e.g., during MlPv6 
handoffs. 



The following EAP-TLV attributes are prefers 
25 keys between HA and MN: 



bly defined for distribution of security 



EAP-TLV attribute 



vii) HA-MN Pre-shared Key Generation Nonce 
This represents the octet string generated rando ;nly by MN as a seed for generating the 
pre-shared key between HA-MN. The MN cai internally generate the HA-MN pre- 
30 shared key by using an appropriate hash algonthm on the combination of this nonce 
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and the shared key between MN and AAAh. 
HA-MN pre-shared key already exists, e.g., 



This attribute is optional when a valid 
during MIPv6 handoffs. 



The KeylD is generated by the AAAh 



viii) IKE KeyJD EAP-TL V attribute 
This represents the ID payload defined in [7]. 
and sent to the MN upon successful authentication. The KeylD includes some octets 
which informs the HA how to retrieve (or generate) the HA-MN pre-shared key from 
AAAh. This attribute is optional, and would generally not be needed when the MN did 
not submit a HA-MN pre-shared key gencratio > nonce, i.e., a valid HA-MN pre-shared 
key already exists, e.g., during MIPv6 handoffs. It is also not needed for the case when 
the HA-MN pre-shared key is conveyed by the AAAh to the HA via the AAAh-HA 
interface defined in [2]. 

fx; HA-MN IPSec SPI EAP-TL V attribute 
This represents the Security Parameter Index f >r IPSec between the HA and MN. This 
is generated by the HA and informed to the MN for the case when the HA-MN pre 
shared key is conveyed by the AAAh to the HA via the AAAh-HA interface defined in 
[2]. This attribute is optional and is generally rot needed when the MN did not submit 
a HA-MN pre-shared key generation nonce 
already exists, e.g., during MIPv6 handoffs. It 
AAAh-HA interface defined in [2] is not used. 



i.e., a valid HA-MN pre-shared key 
is also not needed for the case when the 



x) HA-MN IPSec Key Lifetime EAP-TL V attribute 

This represents the Key Lifetime for IPSec bet wen the HA and MN. This is generated 
by the HA and informed to the MN for the case when the HA-MN pre-shared key is 
conveyed by the AAAh to the HA via the A\Ah-HA interface defined in [2]. This 
attribute is optional and is generally not needed when the MN did not submit a HA- 
MN pre-shared key generation nonce, i.e., a valid HA-MN pre-shared key already 
exists, e.g., during MIPv6 handoffs. It is also njot needed for the case when the AAAh- 
HA interface defined in [2] is not used. 
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Finally, the following EAP-TLV attribute is! preferably defined for distribution of 

i 

security keys between PAC and PAA for PAN A security: 

i 

j 

xi) PAC-PAA Pre-shared Key Generation Nonce EAP-TLV attribute 
5 This represents the octet string generated randomly by MN/PAC as a seed for 
generating the pre-shared key between PAC-PAA. The MN/PAC can internally 
generate the PAC-PAA pre-shared key by using an appropriate hash algorithm on the 
combination of this nonce and the shared key between MN and AAAh. This attribute 
is needed for P ANA security. 

10 ! 

Preferred schemes for handling MIPv6 initiation and handoff according to the 
invention are provided in the signaling flow diagrams Figs. 2, 3 and 4. The illustrated 
examples relate to MIPv6 AAA using a combination of PANA and Diameter as carrier 
protocols. The flow diagram in Fig. 2 illustrates MIPv6 initiation with use of an 
15 AAAh-HA interface according to [2] for exchange of a HA-MN pre-shared key. 
Another MIPv6 initiation scheme, illustrated in Fig. 3, uses IKE KeylD for exchange 
of a HA-MN pre-shared key. The signaling floVs of Fig. 4 describe MIPv6 handoff in 
accordance with an examplary embodiment of the invention. 

j 

20 Concluding remarks/Benefits of the invention \ 

j 

A major advantage of the proposed EAP protocol is that it allows EAP to carry 
MIPv6-related auxiliary information in addition the main MIPv6 authentication 
information. This auxiliary information may include requests for dynamic MN home 
address allocation, dynamic Home Agent allocation, as well as nonces/seeds for 
23 creation of necessary security keys. The MlPv6-related auxiliary information are 
exchanged between the Mobile Node and AAAh (home AAA server), and there is no 
need for intermediaries like AAA Clients and AAAv (visited AAA servers) to 
understand the information. 
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Without the proposed solution, i.e. if EAFj was not carrying the MIPv6-related 

auxiliary information, requirements would typically be placed on the carrier protocols 

i 

like PANA and Diameter to cany this information. This leads to an increased 
complexity of the carrier protocols and to compromised security (as the information is 
5 also picked up by intermediaries AAA Clients and AAAv's). 

To sum up, the invention achieves a complete MlPv6 AAA solution for the first time, 
and does not put unnecessary complexities 'on carrier protocols. It also enables 
security of information between the Mobile N6de and home AAA server. 

10 

Although the invention has been described with reference to specific exemplary 
embodiments, it also covers equivalents to the described features, as well as 
modifications and variants obvious to a man skilled in the art. 
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